1.1 Field of the Invention
The present invention relates to programming and operation of applications for use with devices having a reduced support of high-level programming concepts, particularly for use with SmartCards, it relates in particular to improvements for programming read and write operations on such devices.
1.2 Description of Prior Art
Since a chip card was introduced for public telephones in France 1984, the chip card business has been rapidly growing concerning economic and technological aspects. Until the year 2000 an annual growth of 25 percent is expected. The German Geldkarte has been issued over 40 million times. Former simple storage chipboards evolved to modern SmartCards with their own microprocessor, own operation system and over 32 Kbytes free storage for applications. Very reliable authentication, electronic signature and cryptography are tasks where SmartCards are superior to traditional technologies like magnetic stripe cards. The integrated processor allows SmartCards to operate independently and not influenced by the environment: Sensible data, e.g. a secret key, never has to leave the card. Smart cards are able to execute cryptographic algorithms or check passwords locally before releasing stored data. Electronic cash transactions can be performed this way without an expensive online connection to host systems. This is why SmartCards play an important role especially in electronic business and banking.
Another important area of applications are consumer electronics: Mobiles and set-top-boxes already adopt SmartCard technology. Finally, in some years there will be a new generation of small electronic devices, i.e. reduced resources computer device which are mass produced low cost devices for a variety of daily-life purposes each holding a processing chip and some program memory.
Common to both types of devices is that they are characterized by having a reduced support of high-level programming concepts.
At least one major obstacle impedes the propagation of such devices and in particular of SmartCards and their application development: The software development problems involved with storing and reading on/from such devices.
Storing of objects, i.e. programming objects as an element of object-oriented programming (OOP) techniques is an essential subject of object-oriented software development. Storing an object comprises both, storing the attributes describing the object, and storing the status in which (OOP) methods and algorithms are when the object is stored, in order to be able to continue the methods and algorithms easily and consistently after any reset or interruption of a program having performed any operations on the objects.
Such highly developed storing methods can hardly be used, however, on reduced resources computer devices, i.e. any devices, holding a chip which is small in size and of very limited computing power and storing capacity. Further, they cannot easily be performed on above said devices having a reduced support of high-level programming concepts.
Filesystem-oriented SmartCards are an important example for such devices. On such SmartCards any information is stored by using traditional file structures.under the close memory space and file access constraints particular for such devices. Such structure contains a collection of simple file types and corresponding file directories in order to store the application data belonging to a host application the SmartCard is used with. Data are exchanged between host computer and SmartCard by using a plurality of single instruction sequences, abbreviated commonly as APDU, which carry the data as a trail behind the respective instructions and passing into and from the SmartCards mostly through a two pole contact only.
Such file system oriented SmartCards are the most commonly used ones and are the cheapest, compared to so-called JavaCards, the development of which is not yet completed. Such JavaCards are able to store complete SmartCard applications in form of Applets, and they can even perform them autonomously. In such cards said simple data types as well as complete programming objects can be stored. Such a comfortable storing procedure is, however, only possible to be realized by the SmartCard application itself and cannot be triggered by the host application for exchanging data with the respective SmartCard application. When the host application has to store any object on a JavaCard the traditional procedure of transmitting APDUs must be performed in order to exchange data.
When, however, data are transmitted in APDUs then the application developer has to take care on data formats in order to arrange all data in an adequate form on the SmartCard. This task requires a lot of specialized skill, specific for each SmartCard filesystem architecture.
In order to illustrate said data management problem the application programmer is confronted with, a small and simple example is given next below.
An application object is deemed to describe a bank account. The class name is xe2x80x9cBankAccountxe2x80x9d. It has the attributes xe2x80x9cAccountxe2x80x9d and xe2x80x9cCreditLimitxe2x80x9d. Apart of that the class comprises the programming methods xe2x80x9cWithdraw ( )xe2x80x9d, xe2x80x9cDeposit( )xe2x80x9d and xe2x80x9cGetNumberOfTransactions ( )xe2x80x9d. The application developer has now to read out the particular attributes from the object and has to store them on the SmartCard specific for the respective object each, separately. Thus, Account and CreditLimit, as well as an internal counter of the GetNumberOfTransactions-method, necessary for intermediate storing of the current number of SmartCard accesses have to be treated in that complicated way.
As the application developer has to store the particular data each separately and maybe in a plurality of different ways, each way specific for a specific SmartCard type an application developer cannot take great advantage of the software development comfort which is brought with object-oriented applications, e.g. visual programming methods, as the SmartCards only support the above mentioned simple data types. The application developer has to convert objects explicitly into the simple data types supported by the SmartCard for which the application is designed. Such tasks interrupt a quick and straight forward object-oriented software development and complicates visual programming techniques.
An alternative, to take JavaCards in order to handle complex objects on SmartCards, too, is not easy to be realized as JavaCard technology is still not ready for use, expensive and not yet sufficiently standardized. Thus, the most important SmartCard sector today is that one with traditional filesystem-oriented SmartCards.
Therefore, it is an object of the present invention to improve software development for computing devices having a reduced support of high-level programming concepts and in particular for SmartCard applications by providing an object-oriented programming access to SmartCards as well.
This object of the invention is achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective subclaims.
The objects to be stored on a SmartCard or on a similar device in the above mentioned sense are output from the host application computer in a serialized form adapted to the device, particularly in form of a byte array which can easily be stored on such a SmartCard. Said serialization comprises to convert any particular object into a sequence of bytes representing the object and its current status by storing all attributes, the name of them and all further objects which are referenced by the object which is subjected to that serialization. With the total of said information said object can be principally recovered later in time or in conjunction with another host application terminal being placed at a different location including the updates which were made before. Further, the objects can be recovered in an unchanged form after any reset or interruptions which can possibly take place during usage of the SmartCard in a respective SmartCard terminal. The recover procedure is performed in analogous form: the object as well as all further objects being referenced by that object is instantiated and is initialized with the data read out from the SmartCard. The byte array representing that object can be stored both on common filesystem-oriented SmartCards and on JavaCards, too, without being confronted to any specific further problem.
The method of the present invention with the characteristics of claim 1 has the advantage, in relation to the method sketched out in the discussion of prior art technique that business objects like JavaBeans can be stored in an integral form including the attributes and the methods of an object contiguously and in one single step, instead of storing a plurality of single attributes or defining specific file formats. This simplifies application engineering extraordinarily: the application developer defines his own objects and need not take care of the binary representation thereof.
In a preferred embodiment of the inventional method applied to Java applications it is advantageous to simply realize that serialization step by taking usage of the xe2x80x9cObject Serializationxe2x80x9d which forms part of Java 1.1.
It is thus possible to extend the use of Java Bean items in order to apply such item technology on specific methods for handling such objects for programming purposes, like storing and reading the objects.
In a further preferred embodiment the objects are packed in TLV formatted form, i.e. Tag, Length, Value, and are compressed before being stored. This increases the usage efficiency of the limited memory space on such SmartCards and similar devices.
Thus, SmartCard application data becomes more transparent, handling of such data becomes simpler and more flexible as all data types of the applied object-oriented programming language are provided. A specific skill on SmartCard file system structures is not required for the application developer.
By providing an object-oriented application development for state of the art file system oriented SmartCards they can be used for the development of innovative software solutions which can be performed with modern object-oriented software development techniques including visual programming techniques. Thus the basic principle of the present invention closes a gap between modern programming techniques and their applicability on devices having a reduced support of high-level programming concept such as SmartCards. Closing that gap is important as new JavaCards are not yet fully developed and will be much more expensive than file system oriented SmartCards.
Thus, by aid of JavaBean technology SmartCard applications in Java can be put together out of simple and flexible software elements comprising the application data which can be stored without separate programming efforts as a whole unit on any SmartCard.
Such elements provide for assembling complex structures of SmartCard information by visual programming techniques without any specific skill on SmartCards and without a longer skill on the subject. Taking the proposed Java Serialization in order to perform the proposed conversion offers the advantage of a well accepted quasi-standard concerning the storing format of the object states.
Further, requirements for larger memory space compared to the requirements of conventional, optimized card layout can be equilibrated and balanced due to the above mentioned advantages and due to the clearly recognizable trend towards SmartCards with steadily increasing memory space.
Furthermore, the proposed method requires no JavaSmartCard technology but can, however include JavaSmartCards for usage.
Furthermore, a persistent storage of object status can be achieved and be used for elegantly using complex own classes of an object-oriented application in conjunction with SmartCards.
Finally, this approach is predestined for visual software engineering in which the programmer generates his application objects and connects them by events quasi-intuitively in a graphical environment.